Introduction 

The PATHWORKS network operating system soft- 
ware provides remote file service to desktop com- 
puting devices across a local area network. Inte- 
gration of personal computers (PCs) on a network 
allows users to share applications, files, and print- 
ers. Most applications available on the desktop can 
be used in a manner that consumes widely varying 
amounts of that single-point resource known as the 
file server. 

Some of this variation is due to the intentional 
part-time nature of the server's resource utilization, 
and some is caused by innocent changes in the user 
community's work techniques. Since desktop appli- 
cations are used by novices and experts alike, small 
changes in the levels of skill, experience, and thus 
technique can significantly affect the performance 
of the server. 

Capacity planning is a method of estimating the 
changi ng hardware needs for a computer system due 
to changes in workload. It can also be used to ex- 
plore "what-if" alternatives for existing workloads. 

Changes in user work habits such as running 
macros can increase a server computer's response 
time by as much as an order of magnitude. I n addi- 
tion, simplistic rules of estimating the consumption 
of server resources, such as number of users per 
VUP (VAX- 11/780 unit of performance), can be very 
misleading. The use of applications in ways that 
increase individual productivity can slow server re- 
sponse time for the user community. These issues 
should be considered when selecting a file server 
system. Because the number of active users is of- 
ten unknown in client-server environments and the 
user application technique may vary, capacity plan- 
ning uses a model of the actual workload to predict 
server performance and help define configuration al- 
ternatives. 

This paper describes a queuing analytical model 
that was used to gain knowledge about resource 
consumption on the PATHWORKS server computer. 
The paper discusses the special modeling process 
required for the client-server environment. It de- 
scribes data capture and workload classification us- 
ing DECperformance Solution software. Finally, the 
paper presents the results of a performance anal- 
ysis of a PATHWORKS server with response-time 
constrai nts. 

Some of the terms found in this paper have spe- 
cific definitions. Many of the "correct" terms for net- 
work file serving are not the terms used by users of 
these systems. Network file serving has acquired 
the name "networked." Server computers are often 
referred to as "the network," and getting access to 



one's files on the server is usually called logging into 
"the network." In this paper, we refer to MS-DOS- 
based PCs and Macintosh computers generically as 
desktop computing devices. In addition, the word 
"workload" refers to the cause of the resource con- 
sumption, which is the combination of client appli- 
cation and user technique within that application. 
The term "workload class" has a specific definition 
in DECperformance Solution software. It refers to 
a group of VMS processes that the modeler wants 
to manipulate differently from other processes. 



Defining the Question 

PC users on an integrated PATHWORKS network 
need to determine which server computer system is 
appropriate to their workloads today, and which will 
be appropriate as their numbers increase in the fu- 
ture. The system they choose must deliver sufficient 
performance today and allow a method to plan for 
expanded needs in the future. U sers of desktop com- 
puting devices, which are not networked, can benefit 
from a series of anecdotal model case studies which 
describe other workloads and the file servers which 
were recommended. This paper gives the results 
of our efforts to gain insight into the reasons for 
and symptoms of server resource exhaustion (bot- 
tlenecks) on PATHWORKS file server systems. 



Analytical Models 

PATHWORKS software takes advantage of the ex- 
panded computational power of the client-server ar- 
chitecture, which requires special modeling tech- 
niques. Two of Digital's analytical modeling tools 
can be used in our capacity modeling process, how- 
ever, DECperformance Solution was the primary 
tool. The model was used to answer questions about 
the need to enhance file server computer resource 
requirements as a result of changes in hardware or 
workload. 

Performance models can answer at least two ques- 
tions.[l] First, "How is performance affected if we 
change either the number of users or the amount 
of hardware?" Second, "How can we maintain per- 
formance if we add users doing the same kinds of 
tasks?" Of the two, the second question is the one 
we seek to answer when we model PATHWORKS 
client-server workloads. 

Data Collection 

Data can be collected with the VAX Performance 
Advisor (VPA) version 2.1 or the DECperformance 
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Solution version 1.0 or later. DEC performance So- 
lution software is an integrated product set that pro- 
vides performance and capacity management capa- 
bilities for computing systems. This layered soft- 
ware product runs on the VAX VMS operating sys- 
tem and uses a queuing analytical model to answer 
questions. This process requires collection of two 
kinds of information. 



1. A detailed record of the cause of resource con- 
sumption, including which process is causing 
each disk or CPU activity. Processes should 
be combined into like groups, called workload 
classes, which may be manipulated indepen- 
dently. For example, some workload classes may 
be reduced or eliminated and some may be in- 
creased. 



2. As detailed a record as possible of the effect of re- 
source consumption, including the effect on mul- 
tiple remote clients. Changes in performance are 
typically measured by the elapsed time from the 
carriage return to the return of the prompt. In 
the case of a timeshare user, this is a closed loop 
since almost the entire process is visible to the 
data collector. 



In a PATH WORKS environment, such data cap- 
ture is not possible. A data collection device run- 
ning on the server computer cannot determine the 
number of users for whom the PATH WORKS server 
process is consuming resources. Furthermore, the 
collector cannot detect the response time seen by 
the users of the desktop devices. 



We have developed a general process that can be 
applied toall client-server workloads. These include 
applications such as VTX or VAX Notes, in which 
the number of users initiating the server process' 
resource consumption are unknown to a data collec- 
tor. 



Figure 1 illustrates a simplified closed queuing 
model of a PATHWORKS transaction. The user ini- 
tiates the transaction through a keyboard or point- 
ing device. The application running on the desktop 
computer performs the initial local processing and 
issues a call to the server requesting I/O. The server 
performs some remote computing, and the I/O re- 
quest is satisfied when the server transmits either 
the data or acknowledgment that the data has been 
written. This travels back to the user's desktop de- 
vice and some further computing leads to a graphic 
indication to the user to proceed to the next step. 
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Figure 1 Simple PATHWORKS Queuing Model 



If these three sequential queues— client, network, 
and server computer— were equal in response ti me, 
the server would have only a one in three influ- 
ence on the responsiveness the desktop user sees. 
Of course in reality the three queues are never 
equal, and the two local queues are highly depen- 
dent on the local desktop computer's capabilities. 
Each queue can have a request backlog if the ser- 
vice time is not faster than the arrival rate. The 
response time of any queue is the queue wait time 
plus the actual time to be serviced. The total re- 
sponse time of the workload class, as modeled on 
the server, is the analytic sum of all its queues' re- 
sponse ti mes. 

In reality, the analytical model of the PATH- 
WORKS environment is more complex than the 
one shown in Figure 1 and involves disk, mem- 
ory, and CPU queues. The response time calculated 
for a PATHWORKS server computer workload class 
is the calculated sum of the response times of all 
server process queues for that workload class. As 
stated earlier, this is only an indicator of a desktop 
user response time. 

Cause and Effect 

A data collector, running on the server computer 
is not aware of the response time perceived by the 
user at the desktop device, nor can the server's data 
col lector process know how many users are generat- 
ing the current workload. Server response time is 
a subset of the response time as seen at the desk- 
top and if the server's response time improves, the 
user's will i mprove as wel I , as shown in Figure 1. 

A model that is built from a data collector which 
has only a partial definition of the whole loop (i.e., 
the server computer portion as shown in Figure 1) 
is called an open model. [2] The models described 
in this paper are open models. Since the most 
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likely bottleneck is the shared resource known as 
the server, this is a useful way to model cl ient-server 
workloads. 



Uniform Service Level 

Model analysis of a PATH WORKS client-server 
computer workload cannot predict the increase or 
decrease i n response ti me seen by the user. A model 
can determi ne the effect of any change i n hardware 
configuration or arrival rate (number of users). Ca- 
pacity planners can use this method to add more 
users by incrementing arrival rates. Then hardware 
can be upgraded until an equal or faster server re- 
sponse time is reached. This method can be used 
to increase the number of users at the same perfor- 
mance or split users into smaller groups with the 
same or better performance.[l] 

Not all desktop transactions require server inter- 
vention. I n fact, the success of the client-server ar- 
chitecture depends on infrequent access to servers. 
Obviously, file servers are required when a file is 
saved. However, many applications perform disk 
I/O without any obvious or explicit user action. For 
example, WordPerfect software provides a tempo- 
rary file that is a type of journal file. Periodically, 
the application updates this file with data stored in 
memory. When a user's input reaches a predefined 
buffer limit, the next keystroke causes the file to 
be written. The capabilities of this application, and 
many others, must be considered when planning the 
capacity of a PATHWORKS file server installation. 
In this example, the load per client on the server 
can be significantly reduced by placing the tempo- 
rary file on a local hard disk. 

Performance of a file server computer can also 
be affected when expert users employ macro tech- 
niques or when users generate automated output. 
Macros read each instruction from the macro file 
one record at a time, thereby continuously doing 
I/O. Most expert users provide a save as the last 
instruction in the macro, which allows them to be 
absent when the work is being accomplished and 
then saved. This increases server I/O as well. Most 
desktop applications permit automated output. For 
example, some allow form letter generation; some 
computer-aided design (CAD) applications provide 
Bills of Materials. This capability also increases 
server I/O. 

The use of either macro techniques or automated 
output can impact server computer utilization. A 
server that was i ntended to be a part-ti me fi I e server 
can become a full-time I/O device which can rapidly 
exceed it's capacity. 



To illustrate how a small change in environment 
can affect file server performance, we employed a 
Markov model, using a SHARPE queuing model of 
a server environment. Figures 2 and 3 show the re- 
sults. We asked the question "If we had 120 users 
each randomly filing once an hour and each file ac- 
tion took 5 seconds, how often would a user wait 
for another user to complete a file transaction?" We 
discovered that only 14 percent of the time another 
transaction would be running in the server process. 
Then we asked, "What would happen if 5 of the 120 
users started running a macro and this macro did 
I/O for 5 minutes at random intervals within the 
hour?" The remaining 115 users continued working 
as before. I n this case the possibility increased to 
28 percent that a job request would be on the queue, 
24 percent that two job requests were waiting, and 
20 percent that three job requests were present. 
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Figure 2 Low Use with Infrequent Saves 




Figure 3 High Use with Few Macros Running 



I n the same study, less than 5 percent of the users 
changed the way they were working. None of the 
applications was changed. Almost any PC or Mac- 
intosh application can reasonably be used in this 
way. As the smaller group of users became more 
productive, the other 95 percent experienced a sig- 
nificant delay in response ti me. The system capacity 
must be sized to allow for a situation in which user 
activity lessens overall response ti me. 
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Modeling Process 

The modeling process we describe in this paper 
was developed over a two-year period. Before dis- 
cussi ng the model i ng procedures, we I i st the benefits 
and limitations of the process. 

Benefits 

• Determinations can be made as to the numbers 
of PATHWORKS and new workload class users 
required to maintain the same performance. 

• Single-function server computer models, with 
only PATHWORKS workload classes, can have 
non-PATH WORKS workload classes added for a 
more complex environment. 

• The server can be upgraded to maintain the per- 
formance level of growing user communities. 

• Larger user communities can be divided between 
two standalone servers to maintain an acceptable 
level of performance. 

• Stable user communities can be reduced to pro- 
vide equal levels of performance with two smaller 
servers. 

• Hardware trade-offs can be explored. For exam- 
ple, some users can be moved to another disk. 

• Local site management can be made aware of the 
magnitude of daily workload variation; under- 
standing this variation is also part of the model 
process. 

Limitations 

• The model cannot predict response ti me changes, 
at the client, due to changes in server loading. 

• I nformation about the number of users generat- 
ing the applied workload must be collected by 
methods other than using DECperformance So- 
lution software. These methods are detailed in 
the section Capturing Workloads. 

• Although memory can be modeled, increased 
PATHWORKS read or record management ser- 
vices (RMS) cache requirements cannot be antic- 
ipated by the model. When adding users to a 
PATHWORKS server computer, adequate spare 
memory must be allowed to provide the same or 
better cache hit rates. The RMS cache hit rates 
can be determined, without software tools, by ex- 
ecuting a program at the Digital command lan- 
guage (DCL) prompt: (gSYS$U PDATE :AUTOGE N 
SAVPARAMSTESTFILES FEEDBACK, and then 
reading SYS$SYSTEM:AGEN$PARAMS. RE PORT. 

• Avail able modeling tools only allow PATHWORKS 
workloads to be modeled onto VAX VMS servers. 



• Prior to data collection, the server must be 
checked to see if it is tuned for use today and 
for the future, or the recommended server sys- 
tem may be incorrectly sized. [1] 

Capturing Workloads 

DECperformance Solution software requires VAX 
Performance Advisor version 2.1 or later collector 
files named nodename_date.CPD. In addition, ei- 
ther a VPA$SCH EDULE.DAT or a PSDC$SCH EDULE.DAT 
file is required to define the cluster configuration 
and collection schedule. Either a VAX Performance 
Advisor version 2.1 or DECperformance Solution 
version 1.0 Data Collector, or the DECperformance 
Solution Service Delivery Software kit may be used 
to collect data. All three require a license and prod- 
uct authorization kit. 

Enough data must be collected to represent the 
range of a typical workload. The sum of the subjec- 
tive user opinion of performance must be collected 
as well as the tasks the users were performing. If 
this data is not collected, the planner may mistak- 
enly model equal levels of user dissatisfaction rather 
than equal levels of user satisfaction. Subjective 
performance evaluation is always gathered by in- 
terviewing or monitoring users. 

Collections should be made over a series of normal 
workdays to avoid gathering misleading data. We 
have observed two normal workdays with only a 5 
percent difference in the number of desktop users 
logged into the server, yet five times more server 
resources were used. 

Additional data on user activity that is consuming 
resources must be collected by methods other than 
the DECperformance Solution collector. Both the 
Macintosh and MS-DOS server products have inter- 
active DCL software utilities that provide some in- 
formation about the condition of the current server 
process. Command procedures can call these utili- 
ties with a brief DCL command string. For example, 
ADMIN/PC SHOW FILE COUNTERS displays the 
current cache misses and request rates, and AD- 
MIN/PC SHOW FILE SESSIONS shows the client 
device ID, client connections, and open files. The 
size of the server process cache configuration can be 
gathered using the ADM IN/PC SHOW FILE 

CHARACTERISTICS command. If analysis is per- 
formed offsite, a DCL procedurecan gather informa- 
tion about volumes and system logical names, which 
allows user disk assignments to be defined. Finally, 
user authorization resource limits on the server pro- 
cess can be extracted from the system. The Mac- 
intosh server software has similar commands using 
the ADM IN/MSA SHOW CONNECTION command. 
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When the size of the user community is unknown, 
the above data must be used to characterize the 
number of users being modeled. Specific customers 
with large installations or many remote sites need 
quantitative user characterization. In all cases the 
cause of the observed performance characteristics 
must be determined at some quantitative level. 

The data gathered by using the ADM I N/PC SHOW 
FILE COUNTERS and ADMIN/PC SHOW FILE 
SESSIONS commands can be invalidated if desk- 
top devices include automated procedures to attach 
to file services when the desktop device is booted. 
The simple act of activating the client power switch 
should not count that user as explicitly intending 
to use the server computer. On the other hand, ex- 
plicitly connecting to file services and being inter- 
rupted for an unexpected event should not exclude 
that user from the total active user count. Ulti- 
mately, a combination of the total possible and the 
total active connections is needed. 

Defining Workload Classes 

With the DECperformance Solution data collector, 
workload classes are defined prior to starting the 
modeling process. They are defined either by spec- 
ifying the anticipated logical divisions or by deter- 
mining them from the observed performance data. 
DECperformance Solution software provides many 
ways to group processes, e.g., user identification 
code (UIC), resource usage, image name.[3] 

The DECwindows interface to the DECperfor- 
mance Solution performance tool provides an excel- 
lent way to review the data. [4] The graphic display 
of the server process by day along with the subjec- 
tive user characterization can help select the day or 
days to be modeled. The same method can be used 
to determine peak usage hours. Finally, this tech- 
nique can help categorize workload classes by ap- 
plicable processes. Table 1 lists the workload class 
groupings we used. 
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Table 1 
Workload Class Groupings 



Workload Name 



Image Name Selection Criteria 



FILESVS NETBIOS, PCFS_*, PCSA$* 

OVERHEAD AUDIT_SERVER, NETACP, EVL, ERRFMT, OPCOM, JOBCTL, REMACP, CONFIGURE, IPCACP, 
TPSERVER, FILESERV, CSP, SMISERVER 

ABNORMAL PSDC*, VPA$DC_V5, DECC*, SPM, MONITOR 

MAC_FILESVS ATK*, MSAP*, MSAD*, MSAF* 

LAD LAD$KERNEL 

OTHER (All Else) 



Workload Family Workload Member(s) 



PW_DOS FILESVS, OVERHEAD, ABNORMAL 

PW_MAC MAC_FILESVS, OVERHEAD, ABNORMAL 

PW_BOTH FILESVS, MAC_FILESVS, OVERHEAD, ABNORMAL 

PWJ.AD LAD, FILESVS, OVERHEAD, ABNORMAL 

PW THREE LAD, FILESVS, MAC FILESVS, OVERHEAD, ABNORMAL 



Workload families are groups of workload classes 
that the data collector can expect to see. The PW_ 
DOS workload family characterizes a system as 
a PATHWORKS file service environment. It in- 
cludes PATHWORKS server processes, required sys- 
tem overhead functions, and processes needed to 
collect data that are not normally part of the sys- 
tem. All other processes are automatically placed in 
a category called "other." This suits the needs of our 
general -case, single-function PATHWORKS server 
computer, but any server can be used for tasks un- 
related to the PATHWORKS print and file service. 
If the tasks in the default (other) category need to be 
subdivided for separate scaling, the workload class 
definitions have to be added to a family which calls 
each workload class explicitly, as indicated for the 
PW_LAD workload class family in Table 1. 

For example, to answer the question "As groups of 
ALL-I N-l system users change to PCs, how many 
users can the PATHWORKS server computer sup- 
port?" This determination requires defining another 
workload class by UIC for the ALL-I N-l system 
users. The workload class could be moved by UIC 
to the FILESVS workload class. This method as- 
sumes the current collection of FILESVS workload 
classes reflects the mix of the remaining ALL-I N-l 
system users. 

Prior to the model building step, the PSDC$DATABASE 
logical must be pointing to the location of the 
VPA$SCH E DU LE .DAT and the VPA$PARAM S.DAT 



files. The model building step generates a model 
with the workload class groupings given in Ta- 
ble 1. The workload class and family definitions 
are made using the DCL command ADVISE PLAN 
EDIT in theVPAA/ME (VAX Performance Advisor 
A/AXcluster Modeling Environment) utility and are 
written to a file named VPA$PARAM S.DAT. (If the 
DECperformance Solution tool is used, the files are 
named PSDC$SCH E DU LE .DAT and PSDC$PA RAM S.DAT.) 

If this logical is defined while using the DECper- 
formance Solution DECwindows interface invoked 
from the session manager, the logical may not take 
effect in the DCL session in which the model is to 
be built. The command to generate a model can in- 
clude the time selected to be representative and the 
workload class family definition name. A report can 
be generated which describes the newly built model. 
The command used is: 
ADVISE PLAN BUILD/CLASS= 
(USER=PW_DOS)/BEGIN=9-DEC-1991:10:30 -/ 
E N D=9-DEC-1991:11:30/RE PORT/ 
OUTPUT^VIYMODEL.RPT MYMODE L.M DL.[3] 

At this point the model must be validated by 
typing ADVISE PLAN REPORT MYMODEL.MDL 
VALI DATION/OUTPUT=MYMODEL_VALI D.RPT at 
the DCL prompt. All predicted values should be 
within 10 percent of the calculated values.[2,3] A 
CPU validation report for a collected workload in- 
cludes data on throughput, queue length, average 
service time, average response time, and percent of 
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utilization. For the FILESVS workload, the mea- 
sured utilization was 67.7 percent as compared to 
64.7 percent for the model. This 3 percent differ- 
ence is 4.4 percent of the measured value and thus 
well within the 10 percent range. 

Normalizing the Environment 

The next step is to return the system to the nor- 
mal environment. Even though data collectors are 
typically designed to utilize a small amount of sys- 
tem resources, they are not normally part of the 
server workload. Grouping abnormal processes into 
a workload makes it easier to remove them dur- 
ing the DECperformance Solution model process. 
Access to the DECperformance Solution model in- 
terface is achieved through the command ADVISE 
PLAN MODEL MYMODEL.MDL.[3] 

Recording Response Times 

The next step is to solve the model and view 
the calculated response times for the remaining 
workload classes. These are FILESVS, OVER- 
HEAD, OTHER, and any custom-defined classes. 
The OTH E R workload class can be used as a defined 
workload class provided it contains no unexpected 
processes that are using significant resources. The 
calculated response times for the remaining work- 
load classes should be considered maximum times, 
and model manipulations should always seek to at- 
tain these numbers or less. 

If the intention is to capture the PATHWORKS 
workload class for use elsewhere and if the same 
system had significant OTHER workload classes, 
these classes should be removed (turning the server 
computer into a single-function PATHWORKS server). [3] 
This reduces the response times of the remain- 
ing workload classes and requires increasing the 
PATHWORKS workload class until the response 
time returns to the observed value. The increase 
in throughput is proportional to the increase in 
PATHWORKS users accommodated at the same per- 
formance, without the competition of the OTHER 
workload class. 

Model Manipulation 

Basically, the response time can be manipulated 
(1) by decreasing the usage of a significant resource 
(model resource utilization percentages help locate 
the bottlenecks) or (2) by increasing the capacity of 
that resource. 

There are two ways of decreasing the resource 
utilization. If the resource is single-threaded on 
the critical path, as a CPU would be in a non- 
symmetrical multiprocessor (SMP) machine, the 
method is to reduce the number of users by decre- 
menting their arrival rate (called throughput or 



transactions per second [TPS] in various menus) or 
by increasing the speed of the bottlenecked device. 

The model allows for workload class manipulation 
to remove arrival rates of the workload class. As 
this is being done.the original arrival rate must be 
noted so the same changes can be applied to the 
number of users that caused the workload. 

If the bottleneck is not on a single path, its capac- 
ity can be increased by spreading the load across 
another similar device. This can be achieved with 
multiple disks. 

In the ALL-IN-1 system case discussed earlier, 
100 percent of the workload class from the first U I C 
group of ALL-IN-1 system users can be removed 
from the model. [3] If the model is solved at this 
point, all the workload class's response times should 
diminish. If the Fl LESVS workload class through- 
put is incremented in proportion to the additional 
PATHWORKS users and the model is solved again, 
the response times of all workload classes increase. 

The question is: "Has the removal of theALL-l N-l 
system users decreased critical resource usage suf- 
ficiently that their addition to the PATHWORKS 
FILESVS workload class does not increase any of 
the remaining workload class's response times be- 
yond their target?" The answer depends on the per 
capita usage of the critical resource of each work- 
load class. The nature of each workload class may 
be different. For example, PATHWORKS workloads 
do not scale well over SMP processors. The work- 
load class being removed may use more CPU time 
per user than the PATHWORKS F I LESVS workload 
class. 



Findings 

We analyzed a large PATHWORKS workload class 
from a VAX 6000 model 510 system whose CPU uti- 
lization averaged 72 percent. The subjective user 
evaluation was that this system was very near per- 
formance capacity limits, and a fair amount of dis- 
satisfaction was associated with the level of perfor- 
mance. The question was asked "Could this com- 
munity be split in half across two VAX 4000 model 
300 systems with the same or better performance?" 
We immediately agreed this would work, but went 
about proving it with a model. After the work- 
load class was normalized and the response times 
were noted, the workload class arrival rate was re- 
duced by 50 percent and the CPU and disk systems 
were changed to the VAX 4000 model 300. The new 
model was solved, and the response times were sig- 
nificantly worse than with the VAX 6000 model 510 
system. The workload class was halved again, and 
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the resulting response time was still slightly over 
the target. 

This finding was difficult to understand since the 
VAX 4000 model 300 system CPU was now down 
to 36 percent utilized, and only one quarter of the 
users remained. The reason for the inadequate re- 
sponse time was found by studying the queuing 
model. Figure 4 is a simplified model showing two 
CPUs and their queues displayed on a time scale. 
The first is a slower CPU and the second a faster 
one. Since wedid not allow the response time (total 
queue plus service time) to vary, the queue length 
(measured in number of waiting jobs) on the slower 
CPU was shorter. The service time of the slower 
CPU was larger, in proportion to its queue wait 
time, and therefore an interruption by an overhead 
process caused significant loss of processing time 
(response ti me) to be available for the critical work- 
load class.[5] 

Therefore, the general rule became: Slower CPUs 
will be less utilized at the same workload class re- 
sponse time. This result has been seen on two dif- 
ferent customers' workload classes (one with DOS 
and one with Macintosh clients) which were mod- 
eled by different engineers using different modeling 
tools. 
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Figure 4 Server Queue Comparison on 
Different CPUs 



Another surprising result became evident in the 
day-to-day variation at a customer's installation. 
The same two workload classes were analyzed 
across several days to examine typical workday vari- 
ations in workload class resource utilization. Two 
normal workdays were selected by the customer. 
The most intense hours of these two days were dif- 
ferent by a significant factor. On one workday, three 
to five times as many users applied the same work- 
load class as on the other day, yet all experienced the 



same response ti mes. This wide variation is typical 
of client-server workloads. 

Library of Workload Classes 

After we had captured a series of data, we created 
a small library of real workloads that represented 
various conditions. The actual workloads consist 
of a model file that is devoid of user-specific infor- 
mation. Other non-PATHWORKS workloads can be 
added to these models. Alternatively, the numeric 
workload characterization can be added to existing 
models. Using the above methodology, the model 
can be manipulated to determine what system is 
appropriate for this more complex environment. As 
additional installations are analyzed, their model 
files will be added to the I i brary. 

With either the DECperformance or DEC Capac- 
ity Planner modeling tool, the process is the same: 
Change the hardware and modify the throughput to 
maintain or lower the response times of the model 
during iterations. The changes to throughput are 
then applied to the original number of users to de- 
termine the acceptable number of users in terms of 
server computer capacity. 

Although both modeling tools exhibit similar map- 
ping of the quantitative workload class characteri- 
zation, we do not know the units of some of the key 
metrics used. Therefore, entering a workload class 
captured in one model to another model is not rec- 
ommended. 

Summary 

The PATHWORKS network operating system soft- 
ware provides remote file service to desktop com- 
puting devices across a local area network. Capac- 
ity planning of client-server environments requires 
special modeling techniques. DECperformance So- 
lution software provides performance and capacity 
management capabilities for computing systems; it 
uses a queuing analytical model to answer resource 
consumption questions. The modeling process de- 
pends on the collection of enough data to represent 
the range of a typical workload. Additional data on 
user activity that consumes server resources must 
also be collected. Analysis of workload models re- 
veals the reasons for and symptoms of bottlenecks. 
Capacity planning depends on the results of these 
analyses to predict server response times. 
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